Mobile IP (MIP), which is described in IETF RFC 3344, allows users of mobile communications devices to move from one network to another whilst maintaining a permanent IP address, regardless of which network they are in. This allows the user to maintain connections whilst on the move. For example, if a user were participating in a Voice Over IP (VoIP) session and, during the session the user moved from one network to another, without MIP support the user's IP address may change. This would lead to problems with the VoIP session.
A Mobile Node (MN) is allocated two IP addresses: a permanent home address and a care-of address (CoA). The CoA is associated with a node in the network that the user is currently visiting. To communicate with the MN, packets are sent to the MN home address. These packets are intercepted by a Home Agent in the home network, which has knowledge of the current CoA. The Home Agent then tunnels the packets to the CoA of the MN with a new IP header, whilst preserving the original IP header. When the packets are received by the MN, it removes the new IP header and obtains the original IP header. The MN sends packets directly to another node via a foreign agent in the visited network. The foreign agent maintains information about visiting MNs, including the CoA of each visiting MN.
Proxy Mobile IP v6 (PMIPv6), IETF draft-sgundave-mip6-proxymip6-01, describes a Proxy Mobile Agent (PMA) function. This function emulates home link properties in order to make a MN behave as though it is on its home network and allows support for mobility on networks that would not otherwise support MIPv6.
A PMA is usually implemented at the access router. The PMA sends and receives mobility related signalling on behalf of a MN. When a MN connects to an access router having a PMA, the MN presents its identity in the form of a Network Access Identifier (NAI) as part of an access authentication procedure. Once the MN has been authenticated, the PMA obtains the user's profile from a policy store. The PMA, having knowledge of the user profile and the NAI, can now emulate the MN's home network. The MN subsequently obtains its home address from the PMA. The PMA also informs the MN's Home Agent of the current location of the MN using a Binding Update message. The Binding Update message uses the NAI of the MN. Upon receipt of the Binding Update message, the Home Agent sets up a tunnel to the PMA and sends a binding acknowledgement to the PMA. On receipt of the Binding Acknowledgement, the PMA sets up a tunnel to the Home Agent. All traffic from the MN is routed to the Home Agent via the tunnel.
The Home Agent receives any packet that is sent to the MN, and forwards the received packet to the PMA through the tunnel. On receipt of the packet, the PMA removes the tunnel header and sends the packet to the MN. The PMA acts as a default router on the access link. Any packets sent from the MN are sent via the PMA to the Home Agent, which then sends the packet on to its ultimate destination.
It is possible for a MN to roam from one Proxy MIP domain to another. In the example illustrated in FIG. 1, a MN roams from a Home Proxy MIP domain to a visited Proxy MIP domain. To ensure continuity for any sessions that the MN is currently participating in, the MN continues to use its Home Agent (HAh) rather than the Home Agent (HAv) in the Visited Proxy MIP domain, even though the PMA that serves the MN is in the visited domain. In this case, the PMA serving the MN is PMA1v once the MN has moved to the Visited domain.
According to the current PMIPv6 specification, in order for roaming to occur, a tunnel (illustrated in FIG. 1 by a dotted line) is established between the Home Agent HAh and the PMA (in this case, PMA1v) serving the MN in the visited domain. In order to establish a tunnel, a trust relationship is required between HAh and PMA1v. A problem occurs in the roaming scenario, because HAh and PMA1v belong to different Proxy MIP domains. It is possible to establish a trust relationship between HAh and PMA1v. However, this leads to scalability problems, as this would require all HAs in all Proxy MIP domains to have a trust relationship with all PMAs in all Proxy MIP domains in advance of any roaming, which is impractical.
Another problem with roaming between Proxy MIP domains occurs when the Home Proxy MIP domain is in a closed network. A closed network may, for example, be protected by a firewall. This situation is illustrated in FIG. 2. In this case, establishing a tunnel between HAh and PMA1v is impossible unless the firewall between the two networks recognizes that PMA1v is trusted by HAh. The firewall would therefore need to be aware of all of the trust relationships between HAs and PMAs in all Proxy MIP domains.